home *** CD-ROM | disk | FTP | other *** search
- From: Dan Holmsand <dan@et.se>
- Message-ID: <311535F1.562A@et.se>
- X-Original-Date: Sun, 04 Feb 1996 23:40:49 +0100
- Path: in2.uu.net!bounce-back
- Date: 05 Feb 96 04:00:46 GMT
- Approved: fjh@cs.mu.oz.au
- Newsgroups: comp.std.c++
- Organization: Affdrsvdrlden
- X-Mailer: Mozilla 2.0 (WinNT; I)
- Subject: Re: Give operator. a chance
- X-Auth: PGPMoose V1.1 PGP comp.std.c++
- iQBFAgUBMRWBmuEDnX0m9pzZAQFaZwF+Nz0hDL0ZjFQkqR68m1ukpn5IONpQN/Dx
- O1bPQndcrsEUbnOlmPKHjhw/SFm/eedW
- =FFD/
-
- > Dan Holmsand <dan@et.se> writes:
- > >Is operator.() banned from the standards discussion?
-
- I'm really sorry for reopening this old wound, but many thanks anyway
- for all the answers.
-
- My reason for asking was my own "discovery" that the STL containers and
- algorithms are clearly overrated - sure, they are very efficient indeed
- for simple objects with trivial constructors. However, if you consider
- a vector<vector<string> >, and insert a new element at the beginning of
- the outer vector, the resulting code is clearly less than efficient
- (copy constructing all the strings of all the vectors is everything
- but efficient).
-
- That's why I was hoping for smart references to come to the rescue when
- needed, say by redefining the original vector as
- vector<smart_ref<vector<string> > >, to gain the speed benefit of a
- faster copy constructor, while not having to rewrite all the code
- involved.
-
- #pragma dream on
-
- Another way out would be the ability (and now I am dreaming again, I
- know) to tell the standard algorithms how to move an object from one
- location in memory to another (as opposed to copying them), say by
- means of a couple of simple functions - "move" and "uninitialized_move"
- (corresponding to the copy functions), whose default implementation
- would be to copy construct an object in a new place, and destroy its
- copy in the old location. That function could easily and safely be
- specialized for, say, vector<T, Allocator> and string, to be a simple
- copying of pointers. I guess that nearly all copy constructors could be
- optimized in this way, given that the old copy is guaranteed not to be
- destroyed nor used in the future.
-
- In effect, a standardized "move" function would give the language the
- "move constructor" that the auto_ptr seems to be needing.
-
- That should make, for example, the reshuffling of vectors and sorting
- of containers efficient for "move aware" objects with nontrivial
- constructors.
-
- #pragma dream off
-
- However, the real solution for me will be to ALWAYS use "pointers" in
- collections, since I can always, easily, and without rewriting
- everything change from one smart pointer (say, my current favourite,
- the fabulous gc_ptr<T> :-) to another (containing, say, a real T if the
- profiler says I can live with the copying overhead).
-
- The fact that I can do this, without losing any efficiency and without
- making any hacks in the standard algorithms, has a great deal to say in
- favour of the proposed standard.
-
- Thanks again,
-
- Dan Holmsand
- Affdrsvdrlden
- dan@et.se
- ---
- [ comp.std.c++ is moderated. Submission address: std-c++@ncar.ucar.edu.
- Contact address: std-c++-request@ncar.ucar.edu. The moderation policy
- is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
-